設定ガイド

すべての Red Hat Ceph Storage クラスターには、以下の項目を定義する設定があります。

cephadm などのデプロイメントツールは、通常、初期の Ceph 設定ファイルを作成します。ただし、デプロイメントツールを使用して Red Hat Ceph Storage クラスターをブートストラップする場合には、独自に作成することができます。

Ceph Monitor は、Ceph オプションの設定データベースを管理します。これにより、ストレージクラスター全体の設定オプションを格納することで、設定の管理を一元化します。Ceph の設定をデータベースに一元化することで、ストレージクラスターの管理を簡素化します。

Ceph がオプションの設定に使用する優先順位は以下のとおりです。

ローカルの Ceph 設定ファイル (デフォルトでは /etc/ceph/ceph.conf) で定義できる Ceph オプションはまだいくつかあります。ただし、ceph.conf は Red Hat Ceph Storage 6 では非推奨となっています。

cephadm は、Ceph Monitor への接続、認証、および設定情報の取得のための最小限のオプションセットのみが含まれる基本的な ceph.conf ファイルを使用します。ほとんどの場合、cephadm は mon_host オプションのみを使用します。mon_host オプションのためだけに ceph.conf を使用するのを避けるために、DNS SRV レコードを使用して Monitor で操作を行います。

Ceph では、実行時にデーモンの設定を変更することができます。この機能は、デバッグ設定の有効化/無効化によりログ出力を増減する場合に役立ちます。さらに、ランタイムの最適化にも使用できます。

Ceph の設定オプションには、マスクを関連付けることができます。これらのマスクは、オプションを適用するデーモンやクライアントをさらに制限することができます。

マスクには 2 つの形式があります。

メタ変数は、Ceph ストレージクラスターの設定を大幅に簡素化します。メタ変数が設定値に設定されると、Ceph はそのメタ変数を具体的な値にデプロイメントします。

メタ変数は、Ceph 設定ファイルの [global] セクション、[osd] セクション、[mon] セクション、または [client] セクション内で使用すると非常に強力です。しかし、管理用ソケットでも使用可能です。Ceph メタ変数は、Bash のシェル拡張に似ています。

Ceph は以下のメタ変数をサポートしています。

Ceph 設定ファイルは、ブート時および実行時に表示することができます。

Red Hat Ceph Storage の設定は、Ceph Monitor ノードから実行時に確認することができます。

実行時に特定の Ceph 設定を定義するには、ceph config set コマンドを使用します。

ceph config set mgr mgr/cephadm/manage_etc_ceph_ceph_conf false

BlueStore は、osd_memory_target 設定オプションを使用して、OSD ヒープメモリーの使用を指定されたターゲットサイズで保持します。

osd_memory_target オプションは、システムで利用可能な RAM に基づいて OSD メモリーを設定します。TCMalloc がメモリーアロケーターとして設定されており、BlueStore の bluestore_cache_autotune オプションが true に設定されている場合、このオプションを使用します。

Ceph OSD のメモリーキャッシングは、ブロックデバイスが低速である場合に重要となります (例えば、従来のハードドライブの場合)。キャッシュヒットのメリットがソリッドステートドライブの場合よりもはるかに大きいからです。ただし、ハイパーコンバージドインフラストラクチャー (HCI) や他のアプリケーションなど、他のサービスと OSD を共存させる場合には、この点を考慮する必要があります。

OSD デーモンは、osd_memory_target 設定オプションに基づいてメモリー消費を調整します。osd_memory_target オプションは、システムで利用可能な RAM に基づいて OSD メモリーを設定します。

Red Hat Ceph Storage が他のサービスとメモリーを共有しない専用ノードにデプロイされている場合、cephadm は RAM の合計量とデプロイされた OSD の数に基づいて OSD ごとの消費を自動的に調整します。

ceph config set osd osd_memory_target_autotune true

OSD の追加や OSD の置き換えなど、クラスターのメンテナンスのためにストレージクラスターを Red Hat Ceph Storage 5.0 にアップグレードした後、Red Hat は osd_memory_target_autotune パラメーターを true に設定し、システムメモリーごとに osd メモリーを自動調整することを推奨します。

Cephadm は、mgr/cephadm/autotune_memory_target_ratio の割合で始まります。これはデフォルトでは、システムの合計 RAM 容量の 0.7 になります。これから、非 OSDS や osd_memory_target_autotune が false の OSD などの自動調整されないデーモンによって消費されるメモリー分を引き、残りの OSD で割ります。

osd_memory_target パラメーターは、以下のように計算されます。

osd_memory_target = TOTAL_RAM_OF_THE_OSD * (1048576) * (autotune_memory_target_ratio) / NUMBER_OF_OSDS_IN_THE_OSD_NODE - (SPACE_ALLOCATED_FOR_OTHER_DAEMONS)

SPACE_ALLOCATED_FOR_OTHER_DAEMONS には、任意で以下のデーモン領域の割り当てを含めることができます。

たとえば、ノードに OSD が 24 個あり、251 GB の RAM 容量がある場合、 osd_memory_target は 7860684936 になります。

最後のターゲットは、オプションとともに設定データベースに反映されます。MEM LIMIT 列の ceph orch ps の出力で、制限と各デーモンによって消費される現在のメモリーを確認できます。

[ceph: root@host01 /]# ceph config set mgr mgr/cephadm/autotune_memory_target_ratio 0.2

ストレージクラスターで OSD の特定のメモリーターゲットを手動で設定できます。

[ceph: root@host01 /]# ceph config set osd.123 osd_memory_target 7860684936

ストレージクラスターで OSD ホストの特定のメモリーターゲットを手動で設定できます。

ceph config set osd/host:HOSTNAME osd_memory_target TARGET_BYTES

[ceph: root@host01 /]# ceph config set osd/host:host01 osd_memory_target 1000000000

ceph orch host label add HOSTNAME _no_autotune_memory

自動チューニングオプションを無効にし、特定のメモリーターゲットを設定して、OSD をメモリー自動チューニングから除外できます。

[ceph: root@host01 /]# ceph config set osd.123 osd_memory_target_autotune false
[ceph: root@host01 /]# ceph config set osd.123 osd_memory_target 16G

MDS サーバーは、そのメタデータを別のストレージプール (cephfs_metadata) に保持し、Ceph OSD のユーザーです。Ceph File System の場合、MDS サーバーはストレージクラスター内の単一のストレージデバイスだけでなく、Red Hat Ceph Storage クラスター全体をサポートする必要があるため、特にワークロードが小/中サイズのファイルで設定されている場合 (データに対するメタデータの比率が高い)、メモリー要件が大きくなる可能性があります。

例: mds_cache_memory_limit を 2000000000 バイトに設定

ceph_conf_overrides:
  mds:
    mds_cache_memory_limit=2000000000

高性能な Red Hat Ceph Storage クラスターを構築するには、ネットワークの設定が重要です。Ceph ストレージクラスターは、Ceph クライアントに代わって要求のルーティングやディスパッチを実行しません。代わりに、Ceph クライアントは Ceph OSD デーモンに直接要求を出します。Ceph OSD は Ceph クライアントに代わってデータレプリケーションを実行するため、レプリケーションおよび他の要素によって Ceph ストレージクラスターのネットワークに追加の負荷がかかります。

Ceph には、すべてのデーモンに適用される 1 つのネットワーク設定要件があります。Ceph 設定ファイルは、各デーモンに host を指定する必要があります。

cephadm などの一部のデプロイメントユーティリティーは、設定ファイルを作成してくれます。デプロイメントユーティリティーがこれらの値を設定する場合は、設定しないでください。

すべての Ceph ク ラスターは、パブリックネットワークを使用する必要があります。ただし、内部のクラスターネットワークを指定しない限り、Ceph は 1 つのパブリックネットワークを想定します。Ceph はパブリックネットワークでのみ機能しますが、大規模なストレージクラスターの場合は、クラスター関連のトラフィックのみを伝送する第 2 のプライベートネットワークを使用すると、パフォーマンスが大幅に向上します。

2 つのネットワークをサポートするには、各 Ceph Node に複数のネットワークインターフェイスカード (NIC) が必要になります。

2 つの別々のネットワークを運用することを検討する理由はいくつかあります。

ネットワーク設定の定義は必要ありません。Ceph はパブリックネットワークでのみ機能するので、Ceph デーモンを実行するすべてのホストでパブリックネットワークが設定されている必要があります。しかし、Ceph では、複数の IP ネットワークやサブネットマスクなど、より具体的な条件をパブリックネットワークに設定することができます。また、OSD ハートビート、オブジェクトのレプリケーション、およびリカバリートラフィックを処理するために、別のクラスターネットワークを構築することもできます。

設定で定義する IP アドレスと、ネットワーククライアントがサービスにアクセスする際に使用する公開用の IP アドレスを混同しないようにしてください。通常、内部 IP ネットワークは 192.168.0.0 または 10.0.0.0 です。

ネットワークの設定が完了したら、クラスターの再起動や各デーモンの再起動を行います。Ceph デーモンは動的にバインドするので、ネットワーク設定を変更してもクラスター全体を一度に再起動する必要はありません。

メッセンジャーは Ceph ネットワーク層の実装です。Red Hat は 2 種類のメッセンジャーをサポートしています。

Red Hat Ceph Storage 5 以降では、async がデフォルトのメッセンジャータイプです。messenger タイプを変更するには、Ceph 設定ファイルの [global] セクションに ms_type 設定を指定します。

Ceph ネットワークを設定するには、cephadm シェル内で config set コマンドを使用します。ネットワーク設定で定義する IP アドレスは、ネットワーククライアントがサービスにアクセスする際に使用する公開用の IP アドレスと異なる点に注意してください。

Ceph は、パブリックネットワークとだけ完全に機能します。しかし、Ceph では、複数の IP ネットワークなど、より具体的な条件をパブリックネットワークに設定することができます。

また、OSD ハートビート、オブジェクトのレプリケーション、およびリカバリートラフィックを処理するために、別のプライベートクラスターネットワークを構築することもできます。プライベートネットワークの詳細は、プライベートネットワークの設定 を参照してください。

パブリックネットワークの設定では、特にパブリックネットワークの IP アドレスとサブネットを定義することができます。

ネットワーク設定の定義は必要ありません。Ceph では、クラスターネットワーク (プライベートネットワーク としても知られる) を特に設定しない限り、パブリックネットワーク上のすべてのホストが動作している必要があります。

クラスターネットワークを作成した場合、OSD はハートビート、オブジェクトのレプリケーション、およびリカバリートラフィックをクラスターネットワーク上でルーティングします。これにより、単一のネットワークを使用する場合と比較して、パフォーマンスが向上します。

クラスターネットワークを割り当てるには、cephadm bootstrap コマンドで --cluster-network オプションを使用します。指定するクラスターネットワークには、CIDR 表記のサブネットを定義する必要があります (例: 10.90.90.0/24 または fe80::/64)。

ブースター後に cluster_network を設定することもできます。

ユーザーが複数のネットワークサブネットに属するホスト上に Ceph Monitor デーモンを配置したい場合は、クラスターに対して複数のパブリックネットワークを設定する必要があります。使用例としては、OpenShift Data Foundation の Metro DR の Advanced Cluster Management (ACM) に使用されるストレッチクラスターモードがあります。

ブートストラップ中およびブートストラップの完了後に、クラスターに対して複数のパブリックネットワークを設定できます。

デフォルトでは、Red Hat Ceph Storage デーモンは TCP ポート 6800-​7100 を使用してクラスター内の他のホストと通信します。ホストのファイアウォールがこれらのポートで接続できることを確認できます。

詳細は、ファイアウォールのドキュメントを参照してください。

messenger バージョン 2 プロトコルの導入により、ネットワーク上のすべての Ceph トラフィックの暗号化を有効にすることができます。メッセンジャー v2 の secure モード設定は、Ceph デーモンと Ceph クライアント間の通信を暗号化し、エンドツーエンドの暗号化を提供します。

Ceph デーモンは、レガシー、v1 互換、および新しい v2 互換の Ceph クライアントを同じストレージクラスターに接続することができるように、複数のポートにバインドします。Ceph Monitor デーモンに接続する Ceph クライアントまたはその他の Ceph デーモンは、まず v2 プロトコルの使用を試みますが、可能でない場合は古い v1 プロトコルが使用されます。デフォルトでは、メッセンジャープロトコル v1 と v2 の両方が有効です。新規の v2 ポートは 3300 で、レガシー v1 ポートはデフォルトで 6789 になります。

Ceph Monitor の設定方法を理解することは、信頼性の高い Red Hat Ceph Storage クラスターを構築する上で重要なことです。すべてのストレージクラスターには少なくとも 1 つのモニターがあります。通常、Ceph Monitor の設定はほぼ一定のままですが、ストレージクラスター内の Ceph Monitor を追加、削除、または交換することができます。

Ceph モニターは、クラスターマップのマスターコピーを維持します。つまり、1 つの Ceph モニターに接続して最新のクラスターマップを取得するだけで、Ceph クライアントはすべての Ceph モニターと Ceph OSD の位置を把握することができます。

Ceph クライアントが Ceph OSD に対して読み取り/書き込みを行うには、まず Ceph Monitor に接続する必要があります。クラスターマップの現在のコピーと CRUSH アルゴリズムを使用して、Ceph クライアントは任意のオブジェクトの位置を計算できます。オブジェクトの位置を計算できることで、Ceph クライアントは Ceph OSD と直接対話できるます。このことは、Ceph の高いスケーラビリティーとパフォーマンスを実現する上で非常に重要な要素となります。

Ceph Monitor の主なロールは、クラスターマップのマスターコピーを維持することです。Ceph Monitor は、認証とログサービスも提供します。Ceph Monitor は、モニターサービスのすべての変更を 1 つの Paxos インスタンスに書き込み、Paxos はその変更をキー/値ストアに書き込んで強い一貫性を持たせます。Ceph Monitor は、同期操作中にクラスターマップの最新バージョンにクエリーを行うことができます。Ceph Monitor は、rocksdb データベースを使用したキー値ストアのスナップショットやイテレーターを使用して、ストア全体の同期を実行します。

設定データベースで Ceph Monitor 設定を表示できます。

クラスターマップは、モニターマップ、OSD マップ、および配置グループマップなどのマップを合成したものです。クラスターマップは、多くの重要なイベントを追跡します。

例えば、Ceph OSD がダウンしたり、配置グループがデグレード状態に陥ったりするなど、クラスターの状態に大きな変化があった場合。クラスターマップが更新され、クラスターの現在の状態が反映されます。さらに、Ceph モニターはクラスターの以前の状態の履歴も保持します。モニターマップ、OSD マップ、および配置グループマップは、それぞれのマップバージョンの履歴を保持します。各バージョンは エポック と呼ばれます。

Red Hat Ceph Storage クラスターを運用する場合、これらの状態を追跡することはクラスター管理の重要な部分です。

クラスターは、1 台のモニターで十分に動作します。しかし、1 台のモニターは単一故障点になります。本番環境の Ceph ストレージクラスターで高可用性を確保するには、複数のモニターで Ceph を実行し、1 つのモニターの故障がストレージクラスター全体の障害にならないようにします。

Ceph ストレージクラスターが高可用性のために複数の Ceph Monitor を実行している場合、Ceph Monitor は Paxos アルゴリズムを使用してマスタークラスターマップに関する合意を確立します。コンセンサスを得るには、大半のモニターが動作していて、クラスターマップに関するコンセンサスのためのクォーラムを確立する必要があります。例えば、1、3 つのうちの 2 つ、5 つのうちの 3 つ、6 つのうちの 4 つ等。

Red Hat では、高可用性を確保するために、少なくとも 3 つの Ceph Monitor で本番環境の Red Hat Ceph Storage クラスターを実行することを推奨しています。複数のモニターを実行する場合、クォーラムを確立するためにストレージクラスターのメンバーでなければならない初期モニターを指定することができます。これにより、ストレージクラスターがオンラインになるまでの時間が短縮される場合があります。

[mon]
mon_initial_members = a,b,c

Ceph 設定ファイルにモニター設定を追加する場合、Ceph Monitor モニターのアーキテクチャー的な側面をいくつか知っておく必要があります。Ceph は、クラスター内で別の Ceph Monitor を検出する際に、Ceph Monitor に厳格な一貫性要件を課します。Ceph クライアントおよびその他の Ceph デーモンは、Ceph 設定ファイルを使用してモニターを検出しますが、モニターは Ceph 設定ファイルではなくモニターマップ (monmap) を使用して相互を検出します。

Ceph Monitor が Red Hat Ceph Storage クラスター内の他の Ceph Monitor を検出する場合、常にモニターマップのローカルコピーを参照します。Ceph 設定ファイルではなくモニターマップを使用することで、クラスターが壊れる可能性のあるエラーを回避できます。例えば、Ceph 設定ファイルでモニターのアドレスやポートを指定する際のタイプミスなどです。モニターは検出のためにモニターマップを使用し、クライアントや他の Ceph デーモンとモニターマップを共有するため、モニターマップは、モニターのコンセンサスが有効であることをモニターに対して厳格に保証します。

Ceph Monitor がモニターマップではなく Ceph 設定ファイルを介してお互いを検出する場合、Ceph 設定ファイルは自動的に更新および配布されないため、新たなリスクが発生する可能性があります。Ceph Monitor が誤って古い Ceph 設定ファイルを使用し、Ceph Monitor の識別に失敗し、クォーラムから外れたり、Paxos がシステムの現在の状態を正確に判断できなかったりする状況が発生する可能性があります。

ほとんどの設定とデプロイメントの場合、cephadm などの Ceph をデプロイするツールは、モニターマップを生成して Ceph モニターのブートストラップを支援することがあります。

Ceph モニターには、いくつかの明示的な設定が必要です。

Ceph 設定ファイルの Ceph Monitor の最低限のモニター設定には、各モニターのホスト名 (DNS に設定されていない場合) とモニターアドレスが含まれます。Ceph Monitor はデフォルトで port 6789 および 3300 で実行されます。

以下のコマンドを使用して、ストレージクラスターの設定オプションを設定するか、読み取ることができます。

ここで、WHO パラメーターはセクションまたは Ceph デーモンの名前、OPTION は設定ファイルで、VALUE は true または false のいずれかになります。

ceph cephadm set-extra-ceph-conf

各 Red Hat Ceph Storage クラスターには固有の ID (fsid) があります。指定した場合には、通常は設定ファイルの [global] セクションに表示されます。デプロイメントツールは通常、fsid を生成してモニターマップに保存するため、値は設定ファイルに表示されない可能性があります。fsid を使用すると、同じハードウェア上で複数のクラスターに対してデーモンを実行できます。

Ceph では、Ceph モニターがデータを保存するデフォルトのパスが用意されています。

Ceph モニターは fsync() 関数を頻繁に呼び出します。これは、Ceph OSD ワークロードに干渉する可能性があります。

Ceph モニターは、データをキー/値ペアとして保存します。データストアを使用すると、他のメリットに加えて、復旧中の Ceph モニターが Paxos と通じて破損したバージョンを実行することを防ぎ、1 つのアトミックバッチで複数の修正操作が可能になります。

Red Hat Ceph Storage クラスターが最大容量 (mon_osd_full_ratio パラメーターにより指定) に近くなると、データの損失を防ぐために安全対策として Ceph OSD への書き込みや読み取りができなくなります。そのため、本番環境の Red Hat Ceph Storage クラスターをそのフル比率に近づけてしまうことは、高可用性が犠牲になってしまうのでグッドプラクテイスとは言えません。デフォルトのフル比率は、.95 (容量の 95%) です。これは、OSD の数が少ないテストクラスター用の非常に厳しい設定です。

テストクラスターの一般的なシナリオでは、システム管理者が Red Hat Ceph Storage クラスターから Ceph OSD を削除してクラスターの再バランスを観察します。その後、別の Ceph OSD を削除し、Red Hat Ceph Storage クラスターが最終的にフル比率に達してロックアップするまでこれを繰り返します。

理想的には、Ceph OSD を直ちに置き換えることなく、クラスターが active + clean な状態に復元できる Ceph OSD の一連の障害を計画する必要があります。クラスターを active + degraded の状態で実行できますが、これは通常の動作条件には理想的ではありません。

次の図は、33 台の Ceph Node が含まれる単純化した Red Hat Ceph Storage クラスターを示しています。ホストごとに 1 つの Ceph OSD があり、各 Ceph OSD デーモンは 3 TB のドライブに対して読み取りおよび書き込を行います。つまり、この例の Red Hat Ceph Storage クラスターの最大実容量は 99 TB です。mon osd full ratio が 0.95 の場合は、Red Hat Ceph Storage クラスターが空き容量が 5 TB になると、Ceph クライアントはデータの読み取りと書き込みを許可しません。そのため、Red Hat Ceph Storage クラスターの運用上の容量は 99 TB ではなく 95 TB となります。

このようなクラスターでは、1 つまたは 2 つの OSD が故障するのが普通です。頻度は低いが妥当なシナリオとしては、ラックのルーターや電源が故障し、複数の OSD が同時にダウンすることが挙げられます (例: OSD 7 - 12)。このようなシナリオでは、さらに OSD のあるホストを短い順序で追加する場合でも、動作し続け、active + clean な状態を実現するクラスターを試す必要があります。容量利用率が高すぎると、データを失うことはないかもしれませんが、クラスターの容量利用率がフル比率を超えた場合、障害ドメイン内の障害を解決している間データの可用性が犠牲になる可能性があります。このため、Red Hat では、少なくとも大まかな容量計画を立てることを推奨しています。

クラスターに関する 2 つの数字を把握します。

クラスター内の OSD の平均容量を求めるには、クラスターの総容量をクラスター内の OSD の数で割ります。この数に、通常の運用で同時に故障すると予想される OSD の数 (比較的小さい数) を乗じます。最後に、クラスターの容量にフル比率を掛けて、運用上の最大容量を算出します。そして、失敗すると予想される OSD からデータ量を差し引いて、合理的なフル比率を算出します。前述のプロセスを、より多くの OSD 故障数 (例えば、OSD のラック) で繰り返し、ほぼフル比率のための妥当な数を算出します。

Ceph モニターは、各 OSD からのレポートを要求し、隣接する OSD の状態に関するレポートを OSD から受け取ることで、クラスターについて把握します。Ceph では、モニターと OSD の間の相互作用について妥当なデフォルト設定が用意されていますが、必要に応じて変更することができます。

複数のモニターを持つ本番環境用のクラスターを運用する場合 (推奨される設定)、各モニターは隣接するモニターがより新しいバージョンのクラスターマップを持っているかどうかを確認します。例えば、隣接するモニターのマップのエポックナンバーが、インスタントモニターのマップの最新のエポックより 1 つ以上高い場合。定期的に、クラスター内のあるモニターが他のモニターから遅れをとることがあります。その場合、そのモニターはクォーラムから離脱し、同期をとってクラスターに関する最新の情報を取得した後、再びクォーラムに参加しなければなりません。

これらのロールにより、リーダーは同期のタスクをプロバイダーに委譲しすることができ、同期の要求によりリーダーが過負荷になることを防ぎ、パフォーマンスが向上します。次の図では、リクエスターが他のモニターに遅れをとっていることを認識しています。リクエスターはリーダーに同期を依頼し、リーダーはリクエスターにプロバイダーとの同期を指示します。

同期が完了すると、Ceph ではクラスター全体のトリミングが必要になります。トリミングを行うには、配置グループが active + clean である必要があります。

Ceph デーモンは、クリティカルなメッセージを相互に渡します。このメッセージは、デーモンがタイムアウトのしきい値に達する前に処理する必要があります。Ceph モニターのクロックが同期していないと、さまざまな異常が発生する可能性があります。

以下に例を示します。

NTP では、遅れによる悪影響が出ていなくても、クロックドリフトが目立つことがあります。NTP が適切なレベルの同期を維持していても、Ceph のクロックドリフトとクロックスキューの警告が発生することがあります。このような状況では、クロックドリフトを増やすことが許容できるかもしれません。しかし、ワークロード、ネットワークレイテンシー、デフォルトのタイムアウトに対するオーバーライド設定、およびその他の同期オプションなど、多くの要因が、Paxos の保証を損なうことなく許容できるクロックドリフトのレベルに影響を与えます。

cephx プロトコルはデフォルトで有効になっています。暗号認証には多少の計算コストがかかりますが、一般的には非常に低いものです。クライアントとホストを結ぶネットワーク環境が安全と考えられ、認証の計算コストがかけられない場合は、無効にすることができます。Ceph Storage クラスターをデプロイする際に、デプロイメントツールは client.admin ユーザーおよびキーリングを作成します。

cephx が有効な場合には、Ceph はデフォルトの検索パス /etc/ceph/$cluster.$name.keyring を含む) でキーリングを探します。Ceph 設定ファイルの [global] セクションに keyring オプションを追加することで、この場所を上書きすることができますが、これは推奨されません。

認証が無効になっているクラスターで cephx を有効にするには、以下の手順を実行します。ご自身またはデプロイメントユーティリティーがすでにキーを生成している場合は、キーの生成に関する手順を省略できます。

以下の手順では、Cephx を無効にする方法を説明します。クラスター環境が比較的安全であれば、認証を実行するための計算コストを相殺することができます。

しかし、セットアップやトラブルシューティングの際には、一時的に認証を無効にした方が簡単な場合もあります。

認証が有効な Ceph を実行する場合には、Ceph Storage クラスターにアクセスするために ceph 管理コマンドおよび Ceph クライアントに認証キーが必要です。

ceph 管理コマンドおよびクライアントにこれらの鍵を提供する最も一般的な方法は、/etc/ceph/ ディレクトリーの下に Ceph キーリングを追加することです。ファイル名は通常 ceph.client.admin.keyring または $cluster.client.admin.keyring です。/etc/ceph/ ディレクトリーにキーリングを含める場合は、Ceph 設定ファイルで keyring エントリーを指定する必要はありません。

それを行うには、以下のコマンドを実行します。

# scp USER@HOSTNAME:/etc/ceph/ceph.client.admin.keyring /etc/ceph/ceph.client.admin.keyring

USER を、ホストで使用されるユーザー名に client.admin キーを使用し、HOSTNAME をそのホストのホスト名に置き換えます。

推奨されていない key 設定を使用して、Ceph 設定ファイルにキー自体を指定したり、keyfile 設定を使用してキーファイルへのパスを指定することができます。

管理ユーザーやデプロイメントツールは、ユーザーキーリングの生成と同じ方法で、デーモンキーリングを生成することがあります。デフォルトでは、Ceph はデーモンのキーリングをデータディレクトリー内に保存します。デフォルトのキーリングの場所や、デーモンが機能するために必要な機能など。

デーモンデータのディレクトリーの位置は、デフォルトでは以下の形式のディレクトリーになります。

/var/lib/ceph/$type/CLUSTER-ID

/var/lib/ceph/osd/ceph-12

これらの場所を上書きすることもできますが、推奨できません。

Ceph にはきめ細かな制御機能があり、クライアントと Ceph の間のサービスメッセージの署名を有効または無効にすることができます。Ceph デーモン間のメッセージに対する署名を有効または無効にすることができます。

プールを作成し、プールの配置グループの数を設定するとき、特にデフォルトをオーバーライドしない場合、Ceph はデフォルト値を使用します。

これらの値は、pool コマンドの実行時に設定できます。

デフォルトでは、Ceph はオブジェクトの 3 つのレプリカを作成します。オブジェクトの 4 つのコピーをデフォルト値、プライマリーコピー、および 3 つのレプリカコピーとして設定する場合は、osd_pool_default_size のようにデフォルト値をリセットします。Ceph が劣化状態でより少ない数のコピーを書き込めるようにする場合は、osd_pool_default_min_size を osd_pool_default_size 値よりも小さい数に設定します。

[ceph: root@host01 /]# ceph config set global osd_pool_default_size 4  # Write an object 4 times.
[ceph: root@host01 /]# ceph config set global osd_pool_default_min_size 1  # Allow writing one copy in a degraded state.

配置グループの数が正しいことを確認してください。Red Hat は、OSD ごとに約 100 を推奨します。たとえば、OSD の合計数を 100 で乗算して、レプリカ数で除算します (osd pool default size)。10 OSD および osd_pool_default_size = 4 の場合は、おおよそ(100 * 10)/ 4 = 250 を推奨します。

[ceph: root@host01 /]# ceph config set global osd_pool_default_pg_num 250
[ceph: root@host01 /]# ceph config set global osd_pool_default_pgp_num 250

すべての Ceph クラスターには、以下の項目を定義する設定があります。

cephadm などのデプロイメントツールは、通常、初期の Ceph 設定ファイルを作成します。ただし、デプロイメントツールを使用してクラスターをブートストラップする場合には、独自に作成することができます。

便利なように、各デーモンには一連のデフォルト値が用意されています。多くは ceph/src/common/config_opts.h スクリプトで設定されます。これらの設定は、Ceph 設定ファイル、またはランタイム時にモニターの tell コマンドを使用するか、Ceph ノード上のデーモンソケットに直接接続して上書きできます。

Ceph は、オブジェクトの複数のコピーを作成するだけでなく、配置グループをスクラビングすることでデータの整合性を確保します。Ceph のスクラブは、オブジェクトストレージ層の fsck コマンドに似ています。

各配置グループについて、Ceph はすべてのオブジェクトのカタログを生成し、各プライマリーオブジェクトとそのレプリカを比較して、オブジェクトの欠落や不一致がないことを確認します。

ライトスクラビング (毎日) では、オブジェクトのサイズや属性をチェックします。ディープスクラビング (毎週) は、データを読み込んでチェックサムでデータの整合性を確保します。

スクラビングはデータの整合性を保つために重要ですが、パフォーマンスを低下させる可能性があります。以下の設定を調整して、スクラブ動作を増減させます。

Ceph OSD をクラスターに追加したり、クラスターから削除したりすると、CRUSH アルゴリズムは、配置グループを Ceph OSD に移動させたり、Ceph OSD から移動させたりしてバランスを回復させ、クラスターのバランスを取り戻します。配置グループとそれに含まれるオブジェクトを移行するプロセスは、クラスターの運用パフォーマンスを大幅に低下させます。運用パフォーマンスを維持するために、Ceph はこの移行をバックフィルプロセスで実行します。これにより、Ceph はバックフィル操作をデータの読み取りまたは書き込みの要求よりも低い優先度に設定できます。

クラスターが起動したとき、または Ceph OSD が予期せず終了して再起動したとき、OSD は書き込み操作を行う前に他の Ceph OSD とのピアリングを開始します。

Ceph OSD がクラッシュしてオンラインに戻ると、通常、配置グループのオブジェクトのより新しいバージョンが含まれる他の Ceph OSD との同期が取れなくなります。このような場合、Ceph OSD はリカバリーモードに入り、データの最新コピーを取得してマップを最新の状態に戻そうとします。Ceph OSD が停止していた時間によっては、OSD のオブジェクトや配置グループが大幅に古くなっている可能性があります。また、障害ドメイン (例: ラックなど) ダウンした場合、複数の Ceph OSD が同時にオンラインに戻る可能性があります。そのため、復旧作業には時間とリソースが必要になります。

運用パフォーマンスを維持するために、Ceph はリカバリー要求数、スレッド数、およびオブジェクトチャンクサイズを制限してリカバリーを実行し、これにより Ceph は劣化した状態でも適切なパフォーマンスを発揮することができます。

Ceph の初期設定が完了したら、Ceph をデプロイして実行することができます。ceph health、ceph -s などのコマンドを実行すると、Ceph Monitor は Ceph Storage クラスターの現在の状態を報告します。Ceph Monitor は、各 Ceph OSD デーモンからのレポートを要求し、隣接する Ceph OSD デーモン の状態に関するレポートを Ceph OSD デーモンから受け取ることで、Ceph ストレージクラスターについて把握します。Ceph Monitor がレポートを受信しない場合、または Ceph ストレージクラスターの変更のレポートを受信した場合、Ceph Monitor は Ceph クラスターマップのステータスを更新します。

Ceph では、Ceph Monitor と OSD の連携について妥当なデフォルト設定が用意されています。ただし、デフォルト値を上書きできます。以下のセクションでは、Ceph ストレージクラスターを監視する目的で、Ceph Monitor と Ceph OSD デーモンがどのように相互作用するかを説明します。

各 Ceph OSD デーモンは、6 秒ごとに他の Ceph OSD デーモンのハートビートをチェックします。ハートビートの間隔を変更するには、ランタイム時に値を変更します。

ceph config set osd osd_heartbeat_interval TIME_IN_SECONDS

[ceph: root@host01 /]# ceph config set osd osd_heartbeat_interval 60

近傍の Ceph OSD デーモンが 20 秒の猶予期間内にハートビートパケットを送信しない場合、Ceph OSD デーモンは近傍の Ceph OSD デーモンが down であるとみなされる可能性があります。それを Ceph Monitor に報告して、Ceph クラスターマップを更新することができます。猶予期間を変更するには、ランタイム時に値を設定します。

ceph config set osd osd_heartbeat_grace TIME_IN_SECONDS

[ceph: root@host01 /]# ceph config set osd osd_heartbeat_grace 30

デフォルトでは、異なるホスト の 2 つの Ceph OSD デーモンは、報告された Ceph OSD デーモンが down していることを Ceph モニターが確認する前に、別の CephOSD デーモンが down していることを Ceph モニターに報告する必要があります。

しかし、障害を報告するすべての OSD が、ラック内の異なるホストに設置されており、スイッチ不良により OSD 間の接続に問題が生じる場合があります。

誤報を避けるために、Ceph は障害を報告したピアを、同様に遅延しているサブクラスターの代理として考えます。これは必ずしもそうとは限りませんが、管理者が、パフォーマンスの低下しているシステムのサブセットに局所的に適切な補正を適用するのに役立つ場合があります。

Ceph は mon_osd_reporter_subtree_level 設定を使用して、CRUSH マップの共通の先復元タイプでピアを subcluster にグループ化します。

デフォルトでは、異なるサブツリーからわずか 2 つのレポートは、他の Ceph OSD デーモン down を報告する必要があります。管理者は、mon_osd_min_down_reporters および mon_osd_reporter_subtree_level の値をランタイム時に設定することで、Ceph Monitor に Ceph OSD デーモンの down を報告するために必要な固有のサブツリーと共通の祖先型からレポーターの数を変更することができます。

ceph config set mon mon_osd_min_down_reporters NUMBER

[ceph: root@host01 /]# ceph config set mon mon_osd_min_down_reporters 4

ceph config set mon mon_osd_reporter_subtree_level CRUSH_ITEM

[ceph: root@host01 /]# ceph config set mon mon_osd_reporter_subtree_level host
[ceph: root@host01 /]# ceph config set mon mon_osd_reporter_subtree_level rack
[ceph: root@host01 /]# ceph config set mon mon_osd_reporter_subtree_level osd

Ceph OSD デーモンが、その Ceph 設定ファイルまたはクラスターマップで定義された Ceph OSD デーモンのいずれともピアリングできない場合、30 秒ごとにクラスターマップの最新コピーを求めて Ceph Monitor に ping を実行します。Ceph Monitor ハートビートの間隔は、ランタイム時に値を設定することで変更できます。

ceph config set osd osd_mon_heartbeat_interval TIME_IN_SECONDS

[ceph: root@host01 /]# ceph config set osd osd_mon_heartbeat_interval 60

Ceph OSD デーモンが Ceph Monitor に報告しない場合、Ceph Monitor は mon_osd_report_timeout(900 秒) の経過後に Ceph OSD Daemon を down とマークします。Ceph OSD デーモンは、障害、配置グループ統計の変更、up_thru の変更、または 5 秒以内にブートするなどの報告可能なイベント時に、Ceph Monitor にレポートを送信します。

ランタイム時に osd_mon_report_interval の値を設定することで、Ceph OSD デーモンの最小レポート間隔を変更することができます。

ceph config set osd osd_mon_report_interval TIME_IN_SECONDS

設定を取得、設定、および検証するには、以下の例を使用できます。

[ceph: root@host01 /]# ceph config get osd osd_mon_report_interval
5
[ceph: root@host01 /]# ceph config set osd osd_mon_report_interval 20
[ceph: root@host01 /]# ceph config dump | grep osd

global                  advanced  osd_pool_default_crush_rule                  -1
  osd                   basic     osd_memory_target                            4294967296
  osd                   advanced  osd_mon_report_interval                      20